Priority
We don't rank our three secret scopes. There's no precedence order between them, and one scope never shadows or falls back to another.
How a scope is chosen
The three scopes are stored separately. User, workspace and tenant secrets live in their own
tables. And a secret is always addressed by naming both its scope and the secret itself. Nothing
in the platform picks a scope for you. Whether you can then resolve the secret depends on who you are: a User secret opens only for the user who created it and only inside their current tenant, a Workspace secret opens for users holding MANAGE permission on that workspace, and a Tenant secret opens for anyone in the tenant it belongs to.
Each scope also has its own read rule:
| Scope | Who can resolve a secret in it |
|---|---|
| User | Only the user who created it, within their current tenant. |
| Workspace | Users with MANAGE permission on the workspace the secret belongs to. |
| Tenant | Users in the tenant the secret belongs to. |
We document no cross-scope precedence, override or fallback behaviour. Two secrets with the same name in different scopes are two unrelated secrets; the scope you select is the one that is used.
Scope and secret type
The secret type is independent of the scope. All seven secret types (GOOGLE SERVICE ACCOUNT, AZURE SERVICE PRINCIPAL, AWS ACCESS SECRET KEY PAIR, ENVIRONMENT VARIABLE, DATABRICKS UNITY TOKEN, HIVE BASIC, HIVE KERBEROS) are offered at every scope, and the three scopes share one create form. The only structural difference is the extra required Workspace dropdown on the workspace-scoped form.